The invention relates to messaging broadly, and more particularly relates to a novel system and method for publish/subscribe and point-to-point messaging where multiple HTTP clients requesting next messages maintained in a cache receive a redirect response to each request that identifies a URI for the next message location in the cache using a location field in a standard HTTP redirect mechanism, thereby allowing the HTTP client to automatically iterate through a sequence of next messages so stored.
Publish/subscribe is an asynchronous messaging technology whereby senders publishers of messages) do not send or publish messages to specific receivers (subscribers of messages), but to topics, or named logical channels. Messages are collections of binary or character data that have some meaning to a participating program. Publish/subscribe data processing systems have become very popular in recent years as a way of distributing data messages (publications between application programs). Publishers are typically not concerned with where their publications are going, and subscribers are typically not interested in where the messages they receive have come from. Published messages are characterized into classes without knowledge or regard to which subscribers (if any) should receive the messages such that subscribers typically receive only a subset of total messages published. The publisher is responsible for defining the classes of messages to which subscribers can subscribe.
Publish/subscribe systems may be either topic or content based. In a topic-based system, messages are published to topics or channels associated by topic. In a content-based system, messages are delivered only to subscribers where attributes or message content matches constraints defined by the subscriber, who is responsible for classifying the messages. Publishers and subscribers may also interact with a network of message brokers, each one of which propagates subscriptions and forwards publications to other brokers within the network. Publish/subscribe systems include a message queue manager, a configuration manager and depending on need, a message broker. In such an arrangement, the message broker typically assures the integrity of the message source, and manages the distribution of messages according to valid subscriptions registered with the message broker. A configuration manager drives deployment, including storing and managing configuration data used to configure brokers, and hosted by the message queue manager.
Publish/subscribe systems evolved from WebSphere MQ™, where the WebSphere MQ platform now implements an HTTP interface. As in other communication protocols, storage, routing, and delivery information is added to the message before transmission, and stripped from the message prior to delivery to the receiving application. Message queues are objects that store messages in an application. A queue Manager provides a logical container for the message queue. The queue manager (or message broker) is responsible for transferring data to other queue managers via message channels. Messages are not dependent upon pure packet-based transmissions, such as TCP/IP, to implement the sending publisher) and receiving (subscriber) ends to be decoupled, and potentially operate asynchronously, thereby. Messages are delivered once and once only, irrespective of errors and network problems.
WebSphere MQ networks, and like messaging networks support point-to-point messaging, for example, by use of WebSphere MQ link. WebSphere MQ link is defined on a messaging engine in the service integration bus, and describes the attributes required to connect to, and send or receive messages to or from a queue manager that acts as a gateway to other queue managers. Point-to-point messaging may comprise requests from an HTTP server to WebSphere MQ, optionally followed by a reply, and requests from a network optionally followed by an HTTP server reply.
Addressing messages where multiple clients have access to the same messages in a cache requires that each HTTP client, or each HTTP server, know where each client has read up to in the message cache. Each server maintains a message cache. Such operation effectively requires maintaining a cursor through the messages cache for each individual client. The cursor is typically stored in the HTTP server that maintains it. As such, the server maintains some affinity to the client and on each subsequent request for message(s), increments the cursor for that client. The cursor might also be stored in the HTTP client. Each client thereby “knows” their cursor's position in the cache, and before each request for a message, the client increments its own cursor.
Such conventional use of cursors to maintain a client's last read or next read message position in a cache has limitations. One limitation arises in situations where the message cursor is stored in the HTTP server. In such case, in a multi-server environment (i.e. multiple HTTP servers serviced by an HTTP load balancer), the cursor is shared between all HTTP servers comprising a cluster of HTTP servers. If the cursor is not “shared” between the HTTP servers, subsequent requests for messages by the client could very likely be routed to an HTTP server having no knowledge of that client's cursor.
A second limitation to the conventional use of cursors in a publish/subscribe messaging system arises where the message cursor is stored with the HTTP client. Storing the cursor with the client requires that the client have knowledge of its own message cursor, and requires that the client include the cursor information on each subsequent request. These limitations result in less than optimal messaging processing.